Thanks for this PR! I’m at a conference through tomorrow. I will take a look at this PR on Monday. Sorry for the delay.

Thanks for the additions. I think we need the helm chart first before merging this PR. Per https://github.com/helm/chart-releaser-action I like and have previously used the convention of /charts directory.

Additionally, I feel this needs to be a separate job from build-and-push-image perhaps release-helm-chart or similar.

@DavidNix Thanks for the review, I will work to have that deployed into /charts with the name 'cosmos-operator'. Will test to a local Kubernetes repo and ensure things are starting.

I have created the charts in the directory /charts, however they still need testing before adding the directory to the releaser action config file. Is there a Strangelove dev environment that can be used? I can deploy to my microk8s cluster at home, but I don't want to be solving platform bugs that wouldn't happen in gcp, as making it agnostic can happen in a further PR.

Is there a Strangelove dev environment that can be used?

There is but we have competing priorities at the moment, so we won't be able to set up such an environment for a few sprints. I think microk8s or similar may be the best bet for now.

I'll endeavor to look over this PR by EOW. Thank you!

Fwiw, for the future, I'm hoping there's a pattern where we can use the output of kustomize build to auto populate this helm chart so we don't have to keep the helm chart and kustomize files in sync. At SL, we deploy just fine using kustomize only.

Fwiw, for the future, I'm hoping there's a pattern where we can use the output of kustomize build to auto populate this helm chart so we don't have to keep the helm chart and kustomize files in sync. At SL, we deploy just fine using kustomize only.

Yes I can make that a part of this PR. I did it by hand but can add a pipeline step that passes the output of kustomize to helmify, then we should be able to use those charts as the basis for the release action. Will have that done today, but no rush on your end, I understand things may take priority over QOL enhancements, but hope to make development easier for you and the team :)

Pushing up the latest changes, we currently remove the old cosmos-operator helm chart directory before moving the generating one to ./charts, then pushing directly to main. Do we prefer this have a pull request? if not we may have to allow githubs account to push to protected branches if we still want the feature that every time we change kustomize that it auto generates a new helm chart on merge. We could only have the helm charts as a release object, and not in the repo, however I think that may be confusing for some devs

Pushing up the latest changes, we currently remove the old cosmos-operator helm chart directory before moving the generating one to ./charts, then pushing directly to main. Do we prefer this have a pull request? if not we may have to allow githubs account to push to protected branches if we still want the feature that every time we change kustomize that it auto generates a new helm chart on merge. We could only have the helm charts as a release object, and not in the repo, however I think that may be confusing for some devs

Apologies for my belated response. Last week was unusually busy.

A couple issues:

1. We do not want automation committing and pushing to upstream. This is dangerous from a security standpoint. Instead, opening a PR for a human to review is good. Or, in this case, adding a make action which updates the helm chart and a human commits + opens PR. The make action path may be quickest.
2. A +9,800 PR is extremely large and difficult to review. Some of that is due to the large amount of yaml needed. But there may be areas we can make this PR more manageable.

After some thought, my suggestion is to remove the CICD in this PR and work on just the helm chart itself. We can manually test the helm chart generation + deployment in a test cluster. We add back the CICD workflow in a later PR.

We may not be able to 100% make a helm chart from kustomize build given the user will want to customize attributes in a values.yaml.

Pushing up the latest changes, we currently remove the old cosmos-operator helm chart directory before moving the generating one to ./charts, then pushing directly to main. Do we prefer this have a pull request? if not we may have to allow githubs account to push to protected branches if we still want the feature that every time we change kustomize that it auto generates a new helm chart on merge. We could only have the helm charts as a release object, and not in the repo, however I think that may be confusing for some devs

Apologies for my belated response. Last week was unusually busy.

A couple issues:

1. We do not want automation committing and pushing to upstream. This is dangerous from a security standpoint. Instead, opening a PR for a human to review is good. Or, in this case, adding a make action which updates the helm chart and a human commits + opens PR. The make action path may be quickest.
2. A +9,800 PR is extremely large and difficult to review. Some of that is due to the large amount of yaml needed. But there may be areas we can make this PR more manageable.

After some thought, my suggestion is to remove the CICD in this PR and work on just the helm chart itself. We can manually test the helm chart generation + deployment in a test cluster. We add back the CICD workflow in a later PR.

I think I agree with everything you stated, and appreciate your input. The PR route was my preferred method as well, but didn't want to change until I had your approval. Will look to break these out these out tonight as I have time. Definitely a 2 part PR. I have tested the helm deployment, tho not with everything configured, and can confidently say it deploys, however I think some further testing is in order. :D

Thank you, I appreciate your understanding here and your effort!

FWIW, at Strangelove, we use the kustomize present in the config directory and Flux2 to continuously deploy. It works well and circumvents helm's inability to upgrade CRDs.

Apologies on the delay, this has not been abandoned I've just been sick recently, should wrap this up today & tomorrow.

@justyntemme @DavidNix Is there an update on this PR by chance? I was looking into the Helm chart route for deploying the operator. I'd be happy to help test out if needed. Thanks!